home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20020314-20021006
/
000027_fdc@columbia.edu_Sun Apr 7 14:28:56 EDT 2002.msg
< prev
next >
Wrap
Text File
|
2002-10-06
|
5KB
|
135 lines
Article: 13298 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: a bug on GNU/linux: speed reset to unintended value occasionally.
Date: 7 Apr 2002 14:28:38 -0400
Organization: Columbia University
Lines: 118
Message-ID: <a8q34m$l3l$1@watsol.cc.columbia.edu>
References: <3CAFF81C.8039CBF8@yk.rim.or.jp>
NNTP-Posting-Host: watsol.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1018204119 9015 128.59.39.139 (7 Apr 2002 18:28:39 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 7 Apr 2002 18:28:39 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13298
In article <3CAFF81C.8039CBF8@yk.rim.or.jp>,
Ishikawa <ishikawa@yk.rim.or.jp> wrote:
[ ...a long and detailed posting about a possible bug in
C-Kermit 8.0 in Linux, in which the serial-port speed
seems to change to some random and unwanted value when
CONNECTing or escaping back from CONNECT mode, if hardware
parity (8 data bits + parity) has been requested. ]
Thank you for the excellent report. I was ready to start
a big debugging session, only to find that my Linux PC won't
turn on any more. There's not much I can do at the moment
without a Linux PC where I have hands-on access to the serial
port and can hook up test equipment.
Hardware parity was added in C-Kermit 7.0 at the request of
a small number of people who claimed it was necessary to use
8 data bits plus a parity bit to communicate with certain
devices. I have never had access to such a device so I could
not test it myself, but rather, relied on the test reports of
these people. This is the first indication I have had of a
problem with it.
Since I can't investigate your report right now, let's see
what else can be done.
Has anybody else noticed symptoms like this? Example:
set port /dev/ttyS0
set speed 38400
set parity hardware even
set carrier-watch off ; if necessary
connect
(have a session, then escape back)
show comm
Did the speed change? If so, the next question is:
Does this happen only in Linux, or does it also happen
on other operating systems, such as Solaris?
We know already that the problem has been observed in two
different kinds of Linux: Red Hat 7.2 and Debian (release
unknown).
: PPS: Or maybe certain data structure change
: in the linux kernel might have made the
: previously correct kermit code no longer valid, etc..
:
This kind of thing has happened many times over the history
of Linux, i.e. Linux changes out from underneath Kermit,
thus breaking Kermit (other OS's are not necessarily any
better in this department).
You said you have been doing the same thing in Solaris; did
the problem ever happen there?
If the problem happens only in Linux, I would tend to blame
the Linux serial driver. If it happens in other OS's, the
bug is more likely to be in Kermit.
: I first noticed this on RedHat GNU/linux 7.2
: that uses linux kernel 2.4.x (x being lower than 10, I think).
: The bug was noticed with the Kermit redhat binary/RPM available
: from Columbia university web page.
:
Unfortunately, the C-Kermit RPMs have not been updated to
version 8.0. Personally, I don't have time to learn how to
make packages on 200 different Unix varieties and versions,
so I generally rely on experts in each platform to make packages
of new C-Kermit releases. So far nobody has done this for
C-Kermit 8.0. For package-making considerations, see:
http://www.columbia.edu/kermit/ckpackages.html
: The above log was recorded when there was no
: connection to /dev/ttyS0.
:
>From your log:
: Communications Parameters:
: Line: /dev/ttyS0, speed: 1800, mode: local, modem: generic
: Parity: hardware even, stop-bits: (default) (8E1)
: Duplex: full, flow: none, handshake: none
: Carrier-watch: off, close-on-disconnect: off
: Lockfile: /var/lock/LCK..0
: Terminal bytesize: 8, escape character: 28 (^\)
:
: Carrier Detect (CD): Off
: Dataset Ready (DSR): Off
: Clear To Send (CTS): Off
: Ring Indicator (RI): Off
: Data Terminal Ready (DTR): On
: Request To Send (RTS): On
:
it appears that C-Kermit has the device open, but the device is
not presenting carrier (CD), or Dataset Ready (DSR), or Clear to
Send (CTS). Is that what you mean by "no connection"? In my
experience, Unix serial drivers often act strangely when the
serial port is not receiving any signals from the "modem". Here
are two suggestions:
1. In C-Kermit 8.0, the default modem type was changed
from "none" to "generic". Since you did not give a
"set modem type" command, you are using the "generic"
modem type. Try telling C-Kermit to "set modem type none"
BEFORE you give the "set line" command.
2. I wonder what would happen if you used a true null modem
cable (or adapter), which feeds the other device's DTR
signal into the PC's CD signal, and similarly for the
DSR and CTS signals. Maybe then the problem would go away.
Finally, I'm curious: does the Cisco router really need 8E1? If
that were true, I suspect that very few communications packages
could communicate with it.
- Frank